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1.      Introduction 

It  is  often  noted  that  our  technical   abilities  to  design  and 
build  complex  management  science  (MS)  models  and  sophisticated  manage- 
ment information  systems   (MIS)  have  progressed  quite  rapidly  in  recent 
years.     However,  our  ability  to  translate  these  models  and  systems  into 
tools  useful    to  managers  has  not  kept  pace.     In  almost  any  journal    in 
the  MS/MIS  area,  one  can  find  articles  lamenting  the  current  state  of 
practice;  efforts  to  implement  MS  models  and  information  systems  occas- 
sionally  fail   completely  and  often  run  into  some  sort  of  difficulty. 

A  number  of  researchers  have  attempted  to  explore  this   imple- 
mentation problem,  but,   as  we  shall   see,   their  findings  have  not  provided 
us  with  the  understanding  we  need  in  order  to  improve  the  process.     There 
have  been  two  major  approaches  to  the  study  of  MS/MIS  implementation. 
The  first  of  these,   the  normative  approach,    in  based  on   the  field  ex- 
perience of  a  number  of  MS  researcher/practitioners.     These  researchers 
typically  look  back  at  one  or  more  cases   they  were  involved  in  whore 
there  was  substantial    implementation  difficulty,  and  attempt  to  draw 
out  from  these  experiences  the  general   nature  of  implementation  problems 
and  the  solution  to  these  problems. 

Looking  at  this  normative  literature   in  aggregate,  we  find 
substantial   disagreement  on  just  what  the  solution  to  implementation 
problems  should  be.      Indeed,  we  find  a  number  of  cases  where   the  solu- 
tion  suggested  by  one   researcher  is   in  direct  conflict  with   that    sug- 
gested by  another   .     Ackoff  and  Argyris  provide  and  excellent  example. 


For  a  comprehensive  review,  see  Ginzberg,   1975. 
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Ackoff  (1960,  1967)  has  suggested  two  basic  strategies  which  the  manage- 
ment scientist  can  adopt  to  increase  the  odds  for  success;  first,  he 
should  develop  formal  bases  of  power  within  the  client  organization, 
and  second,  he  should  adopt  and  use  a  highly  rationalized  system  develop- 
ment process.  Argyris  (1971),  on  the  other  hand,  contends  that  formal 
power  and  work  rationalization  are  the  causes  of  implementation  failure; 
the  appropriate  strategy,  then,  is  to  develop  interpersonal  competence. 
Clearly,  these  two  researchers  are  in  direct  conflict  in  their  suggested 
strategies. 

At  least  part  of  this  disagreement  results  from  the  differences 
in  the  way  these  two,  as  well  as  other,  authors  define  the  implementation 
problem.  Each  is  reflecting  on  his  own  experience  in  a  limited  number 
of  cases.  What  is  more,  they  are  dealing  only  with  cases  which  ended 
in  failure.  Thus,  each  author  is  considering  only  a  limited  part  of 
the  spectrum  of  implementation  situations.  This  approach,  based  on  a 
limited  number  of  cases,  can  only  provide  fragmentetd,  anecdotal  results. 
Further,  by  failing  to  consider  successful  implementation  efforts  as  well 
as  failures,  we  have  no  basis  for  comparison  from  which  we  could  develop 
an  understanding  of  the  results.  Thus,  the  normative  approach  to  imple- 
mentation research  can  never  provide  us  with  the  comprehensive  guidelines 
needed  to  manage  MS/MIS  implementation  efforts  in  a  variety  of  settings. 

The  second  major  approach  taken  has  been  the  "factor  study". 
Though  there  are  many  variations  in  the  details,  all  factor  studies 
have  followed  the  same  general  pattern.  They  begin  by  identifying  a 
group  of  variables  potentially  relevant  to  implementation  outcomes. 
Data  are  then  collected  from  a  sample  of  MS  implementation  projects  -- 
some  successful  and  others  not  --  and  these  data  are  used  to  assess  the 


the  relative  importance  of  the  different  variables  (or  factors)  to  imple- 
mentation outcomes. 

As  a  mechanism  for  increasing  our  understanding  of  implementa- 
tion, the  factor  study  represents  a  considerable  improvement  over  the 
normative  approach.  While  the  latter  was  often  based  on  one  or  two 
specific  cases,  the  former  attempts  to  sample  a  range  of  cases.  Similar- 
ly, the  normative  approach  dealt  only  with  failure  situations,  while  the 
factor  studies  include  both  successful  and  unsuccessful  implementation 
efforts.  The  results  of  the  factor  studies,  however,  are  rather  dis- 
appointing. Few  general  guidelines  emerge  from  this  research;  the  re- 
sults of  different  studies  being  contradictory  in  a  number  of  cases.  The 
only  result  which  is  firmly  established  by  this  research  is  the  importance 

of  management  support  and  user  involvement  to  the  successful  implementa- 
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tion  of  MS/MIS  projects  . 

Certain  characteristics  of  the  implementation  problem  itself, 
in  conjunction  with  the  factor  approach  to  studying  it,  contribute  to 
the  sparseness  of  these  results.  First,  there  is  an  almost  limitless 
number  of  potentially  relevant  factors,  and  we  do  not  yet  have  appro- 
priate theories  for  organizing  them.  Research,  therefore,  tends  to  frag- 
mented, exploring  only  a  part  of  the  whole  problem,  and  there  is  no  co- 
herent framework  within  which  to  place  the  results  of  a  given  study. 
Closely  related  to  the  first  problem  is  the  issue  of  contingency.  A 
variable  which  can  affect  implementation  outcomes  may  only  do  so  in  the 
presence  of  certain  other  variables  or  conditions;  if  these  other 


2 
A  more  complete  compendium  and  discussion  of  the  results  of  factor  studies 

of  implementation  can  be  found  in  Ginzberg,  1974  or  1975. 


conditions  are  not  present,  the  first  variable  may  have  no  effect  on  out- 
comes. Simple  analysis  of  the  relationship  between  single  variables  and 
outcomes  will  not  uncover  these  contingent  relationships,  and  may  lead 
one  to  conclude  that  no  relationship  exists  when,  indeed,  one  does. 

A  third  major  problem  with  the  factor  approach  is  its  static 
view  of  the  world.  Factors  are  measured  at  a  single  point  in  time,  and 
it  is  assumed  that  the  measurements  taken  capture  the  essence  of  that  im- 
plementation effort.  This  view  is  woefully  inadequate.  Implementation 
is  inherently  a  dynamic  pheonmenon;  the  state  of  a  given  factor  can  change 
or  be  changed  in  the  course  of  the  implementation  process,  and  no  snap- 
shot view  can  possibly  represent  the  entire  process. 

The  final  shortcoming  of  this  approach  is  its  failure  to  focus 
on  the  management  of  the  implementation  process.  The  concern  has  been 
with  measuring,  classifying  conditions  as  favorable  or  unfavorable  to 
implementation  outcomes.  And,  the  variables  considered  have  been  pri- 
marily those  over  which  we  have  the  least  control  (e.g.,  demographics, 
structure,  environment). 

The  failure  of  these  standard  approaches  --  the  normative  ap- 
proach and  the  factor  study  —  to  provide  us  with  generally  applicable 
results  or  tools  we  can  use  to  guide  our  implementation  efforts,  suggests 
that  we  must  look  for  an  alternative  paradigm  for  implementation  research. 
The  choise  of  an  appropriate  paradigm  is  a  critical  one;  the  paradigm  we 
use  determines  where  we  will  focus  our  attention  and  provides  the  only 
framework  we  have  for  organizing  our  results.  Thus,  the  paradigm  we 
adopt  must  recognize  that  implementation  is  a  dynamic  process,  and  it 
must  attempt  to  bring  appropriate  theory  to  bear  on  this  process  to 
provide  a  more  coherent,  structured,  and  hopefully,  parsimonious  view. 


It  should  allow  the  consideration  of  interactions  among  the  variables 
affecting  implementation.  And,  of  course,  it  should  focus  on  the  manage- 
ment of  MS  implementation,  those  aspects  of  the  process  over  which  we 
have  potentially  the  greatest  control.  The  remainder  of  this  paper  in- 
troduces one  such  approach,  and  discusses  the  results  of  a  recent  study 
which  used  this  alternative  perspective  to  look  at  MS/MIS  implementation 
efforts. 

2.  An  Alternative  View  of  Implementation 

Recent  literature,  both  empirical  and  theoretical,  suggests 
that  we  can  find  a  paradigm  for  viewing  MS/MIS  implementation  which  meets 
the  requirements  outlined  above.  To  do  this  we  must  shift  away  from  our 
past  atheoretical  and  structural  views  of  implementation,  and  towards  a 
process  view.  That  is,  we  must  look  at  MS  implementation  as  a  process 
of  planned  change  in  an  organizational  setting.  This  view  is  theoretically 
justifiable,  but  even  more  important,  it  makes  a  great  deal  of  sense. 
Consider  some  types  of  implementation  problems  raised  in  the  literature  -- 
poor  communications,  emotional  behavior,  resistance  to  change,  failure  to 
deal  properly  with  power.  All  of  these  are  problems  arising  out  of  the 
social  system,  and  are  the  types  of  issues  addressed  by  tl)e  planned  change 
literature.  There  should  be  clear  gains  to  both  managers  and  management 
scientists  in  drawing  from  the  research  and  practice  in  this  area  and 
applying  it  to  our  problems  of  changing  the  technology  employed  in  managing 
an  organization. 

The  theoretical  base  most  frequently  suggested  by  those  who 
advocate  a  planned  change  approach  to  implementation  is  the  Lewin/Schein 


theory  of  change  (see  Lewin,  1952;  Schein,  1961  and  1972).  This  theory 
suggests  that  any  change  effort  can  be  viewed  as  including  three  dis- 
tinct phases  -  Unfreezing,  Moving,  and  Refreezing.  Each  phase  is  con- 
cerned with  changes  in  the  balance  of  "force  fields"  existing  in  the  or- 
ganization, and  the  degree  to  which  they  foster  change  or  resistance  to 
it. 

The  first  phase.  Unfreezing,  entails  the  disconfirmation  of 
existing,  stable  behavior  patterns  --  establishing  a  "felt  need"  for 
change  -  and  the  development  of  an  atmosphere  in  which  the  individual 
feels  he  can  safely  try  something  new.  Both  of  these  changes  in  the 
relevant  forces  are  necessary  before  any  innovative  change  effort  can 
even  get  started. 

Moving  is  the  "action"  phase  of  the  change  effort.  This  re- 
quires the  presentation  of  information  necessary  for  change  and  the 
learning  of  new  attitudes  and  behaviors  which  are  necessary  parts  of 
the  change. 

Refreezing  entails  the  stabilization  of  the  change  and  the  in- 
tegration of  new  attitudes  and  behaviors  into  existing  patterns  and  re- 
lationships. Refreezing,  however,  is  not  meant  to  imply  stagnation.   In- 
deed, the  whole  sequence  of  Unfreezing,  Moving,  and  Refreezing  is  seen  as 
an  iterative  process,  and  will  likely  be  repeated  more  than  once  in  any 
sizable  change  effort  (such  as  the  implementation  of  a  lar-ie  or  complex 
information  system). 

There  are  a  number  of  very  salient  reasons  for  adopting  this 
process  view  of  implementation.  We  have  already  mentioned  the  fit  be- 
tween the  issues  raised  by  this  view  and  the  problems  cited  in  the 
literature.  Beyond  this,  we  should  note  that  it  forces  us  to  look  at 


the  entire  implementation  process  —  from  initial  planning  and  feasibility 
testing  through  installation,  evaluation,  and  frequently,  evolution  -- 
rather  than  only  the  "action"  stage  which  has  traditionally  been  viewed 
as  synonymous  with  implementation.  Many  of  the  problems  which  manifest 
themselves  late  in  a  project's  development  actually  have  their  roots  in 
an  earlier  stage.  Looking  at  the  entire  process  should  help  us  develop  a 
fuller  understanding  of  the  nature  of  these  problems. 

Another  important  characteristic  of  the  process  view  is  the 
freedom  it  allows  us  in  selecting  a  measure  (or  measures)  of  implementa- 
tion success.  The  traditional  view  of  MS/MIS  implementation  has  been  one 
of  installing  a  product.  Within  this  product  view,  the  indicator  normally 
chosen  for  gauging  success  is  system  usage;  systems  which  are  used  heavily, 
or  models  whose  recommended  solutions  are  put  into  action,  are  successes, 
and  vice  versa  for  failures.  The  factor  study  with  its  "after-only", 
snapshot  view  of  a  project  has,  in  most  cases,  accepted  usage  as  the 
criterion  of  implementation  success.  The  process  view  suggests  that  we 
look  at  implementation  not  as  the  delivery  of  a  product,  but  rather  as 
the  performance  of  service.  Our  aim  should  be  to  help  managers  do  their 
jobs  better.  Sometimes  this  will  mean  using  the  system  that  was  develop- 
ed, but  sometimes  it  will  not.  The  process  view  allows  (in  fact,  en- 
courages) us  to  define  success  in  a  manner  which  encompasses  both  situa- 
tions. Essentially,  if  the  manager  is  satisfied  that  the  project  met  its 

goals,  the  project  should  be  termed  a  success,  whether  the  resulting  sys- 

3 
tem  is  being  used  or  not  . 


3 
Huysmans,  1973,  presents  a  formalized  view  of  the  success  issue,  as  well 

as  some  interesting  examples. 


The  final  advantage  we  gain  by  adopting  a  process  view  arises 
from  its  focus  on  the  interaction  between  consultant  (or  designer)  and 
client  (or  user).  The  single  aspect  of  the  entire  implementation  situa- 
tion over  which  we  can  exert  the  most  direct  control  is  that  of  our  own 
behavior,  both  as  users  and  as  designers.  The  process  approach  leads  us 
to  examine  these  behaviors,  to  determine  patterns  which  are  particularly 
effective  or  ineffective  in  achieving  successful  implementation.  And, 
once  these  patterns  have  been  found,  they  can  swiftly  be  translated  into 
strategies  and  tactics  which  users  and  designers  can  employ  to  improve 
the  chances  of  success  in  their  projects.  That  is,  while  earlier  approach- 
es to  implementation  research  focused  on  measuring  or  classifying,  the 
planned  change  approach  focuses  on  managing.  And,  managing  the  process 
is  what  is  needed  to  improve  our  effectiveness  in  applying  MS/MIS. 

3.  Testing  the  Process  View 

A  number  of  recent  articles  have  suggested  that  the  Lewin/Schein 
model  is  an  appropriate  framework  to  use  in  studying  implementation,  and 
there  has  been  one  empirical  test  of  this  assumption.  Sorensen  and  Zand 
(1973)  gathered  data  on  almost  300  projects  —  considered  very  successful 
and  one  very  unsuccessful  from  each  of  nearly  150  management  science 
practitioners.  Their  results  indicate  that  high  levels  of  activity  con- 
ducive to  Unfreezing,  Moving,  and  Refreezing,  as  reported  by  the  manage- 
ment sciencetist,  are  associated  with  greater  project  success,  while  high 
levels  of  activity  antithetical  to  these  stages  are  positively  related 
to  project  failure.  Their  evidence  also  suggests  that  the  Refreezing 
stage  may  well  be  the  most  critical  stage  in  the  process. 


The  study  we  undertook  sought  to  extend  Sorensen  and  Zand's  re- 
sults along   three  dimensions.      In   the  first  place,    the  Lewin/Schein   theory 
is  very  general   and  non-operational.     A  number  of  models  which  elaborate 
on   this  basic  theory  have  been  suggested  in  the  planned  change  literature, 
and  these  models  can  provide  some  of  the  detail   needed  to  begin  defining 
operationally  the  activities  of  and  mechanisms  necessary  for  Unfreezing, 
Moving,  and  Refreezing.     For  our  research  we  have  chosen  to  use  the  Kolb/ 
Frohman  model   of  the  consulting  process   (see  Kolb  and  Frohman,   1970). 
This  model   divides  the  process  into  seven  phases,  adding  more  structure 
and  detail    to  the  basic  framework  provided  by  Lewin  and  Schein   (see 
Figure  1),  and  being  more  directly  translatable  into  managerial   action. 

A  second  area   in  which  our  research  expands  on  previous  studies 
is   in   the  consideration  of  multiple  perspectives.     Each  person  involved 
in  a  MS  or  MIS  project  has  his  own  particular  set  of  needs  and  objectives. 
Satisfying  the  needs  of  one  individual    involved  in  a  project  does  not 
necessarily  imply  that  all   participants  will    be  satisfied.     At  the  most 
basic  level,  we  can  see  that  the  difference  in  role  between  designer  and 
user  almost  surely  implies  a  difference  in  the  needs  and  objectives  they 
bring  to  a  project.     But,  within  each  group  differences  are  also  likely. 
To  fully  understand  an   implementation  effort,   then,  we  want  to  gather 
data  from  multiple  participants,  both  designers  and  users. 

The   third   issue,    that  of  contingency,  was   touched  on   in  our 
discussion  of  factor  research.     We  know  that   implementation  efforts  are 
not  all   alike;   certain  attributes  of  the  total   situation  will    have  marked 
effects  on   the  way  the   implementation  effort  proceeds.     One  variable  which 
we  believe  has  such  an   influence  is  the  type  of  system  that  is  being 
implemented.     The  approach  taken  in  developing  a  straight  forward  payroll 
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The  Kolb/Frohman  Model 
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point  is  chosen 
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commitment  and  trust 
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organization;   developing  action 
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Putting  "best"  alternative  solution 
into  practice;  modifying  action 
plan   if  unanticipated  consequences 
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Assessing  how  well   objectives  were 
met;   deciding   to  evolve  or  terminate 

Confirming  new  behavior  patterns; 
completing  transfer  of  system 
"ownership"  and  responsibility  to 
the  client 


UNFREEZING 
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MOVING  & 
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FIGURE  1 
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system  probably  should  not  be  the  same  as  that  for  a  complex  simulation 
model  to  be  used  for  setting  and  allocating  advertising  expenditures. 
The  implied  organizational  complexity  of  the  payroll  system,  the  amount 
of  change  it  will  require  in  the  user  organization,  is  far  smaller  than 
in  the  case  of  the  simuation  model.  Thus,  our  understanding  of  the  im- 
plementation process  and  our  ability  to  effectively  manage  this  process 
should  both  be  enhanced  if  we  consider  the  particular  technologies  in- 
volved when  analyzing  implementation  data. 

Our  study  employed  fairly  lengthy  questionnaires  to  reconstruct 
within  the  framework  of  the  Kolb/Frohman  model,  the  implementation  pro- 
cess followed  by  a  number  of  MS/MIS  projects.  The  questionnaire  items 
dealt  with  the  various  issues  requiring  resolution  at  each  stage  of  the 
model,  and  the  respondent's  answers  indicated  the  degree  to  which  he 
felt  these  issues  had  been  resolved.  Usable  data  were  collected  for  29 
projects  in  nine  industries;  for  27  of  these,  we  received  responses  from 
one  designer  and  one  or  more  users,  while  for  the  remaining  two  we  ob- 
tained responses  from  users  only. 

The  29  projects  can  be  grouped  according  to  their  implied  or- 
ganizational complexity.  We  must  note  that  organizatonal  complexity  and 
technical  complexity  are  not  at  all  the  same.  Technical  complexity 
arises  primarily  from  the  size  of  the  system  being  implemented  (numbers 
of  lines  of  code,  modules,  or  users).  Organizational  complexity,  on 
the  other  hand,  pertains  to  the  degree  of  change  in  task  definitions 
and  operating  procedures  requried  by  the  new  system.  From  the  imple- 
mentation perspective,  the  latter,  organizational,  issues  are  more 
critical,  as  they  define  groups  of  projects  which  are  qualitatively 
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4 
different  from  one  another  . 

When  we  group  the  projects  according  to  their  organizational 
complexity,  we  find  three  groups  of  roughly  equal  size,  which  are  similar 
internally  and  differ  substantially  from  one  another.  In  the  least  complex 
group  are  systems  which  perform  standard  accounting  and  historical  report- 
ing functions.  For  the  most  part,  these  systems  automate  the  preparation 
of  reports  which  previously  were  prepared  manually,  and  as  such  result  in 
very  little  change  within  the  user  organization. 

In  the  most  complex  group  are  a  number  of  model -based,  manage- 
ment oriented  systems.  Many  of  these  systems  perform  multiple  functions 
or  serve  users  in  multiple  areas  of  the  organization.   In  almost  all  cases 
these  systems  provide  managers  with  access  to  data  and  analytic  capabilities 
which  peviously  was  unavailable  to  them.  Thus,  all  of  these  systems  require 
considerable  change  in  the  user  organization  for  their  successful  integration 

Between  these  two  groups  lie  the  systems  of  intermediate  com- 
plexity. These  are  neither  so  mundane  as  the  systems  in  the  first  group 
nor  so  innovative  as  those  in  the  latter.  Some  examples  of  systems  in 
the  group  include  data  retrieval  systems,  an  inventory  control/bill  of 
materials  processor  system,  and  some  fairly  straight  forward  projective 
models. 

The  following  table  summarizes  the  differences  between  the 
characteristics  of  the  systems  in  the  three  groups: 


Ginzberg,  1975,  provides  a  more  thorough  discussion  of  the  issue  of  com- 
plexity and  of  the  subsetting  of  these  projects. 
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Typical  System  Characteristics 


Characteristics 

Low 

1 ^ r- 

Medium 

High 

ON-LINE  OPERATION 

NO 

50%  of  Systems 

YES 

CLERICAL  USERS 

YES 

YES 

NO 

MANAGEMENT  USERS 

75%  of  Systems 

YES 

YES 

SERVES  MULTI-FUNCTIONS 

NO 

50%  of  Systems 

50%  of  Systems 

SERVES  MULTI-USER 
AREAS 

NO 

NO 

25%  of  Systems 

INCLUDES  PROJECTIVE 
MODELS 

NO 

50%  of  Systems 

YES 

INCLUDES  STATISTICS 
OR  OPTIMIZATIONS 

Seldom 

Seldom 

Frequent 

TABLE  1 

The  data  collected  for  this  study  show  important  differences  be- 
tween successes  and  failures  within  each  complexity  group  in  the  way  the 
implementation  process  was  handled,  as  well  as  differences  across  the 
groups  in  the  activities  that  were  most  critical  to  success.  We  will  dis- 
cuss these  (and  other)  results  in  the  next  section,  and  will  outline  some 
of  their  implications  for  managers  and  management  scientists  in  the  final 
section. 

4.  Discussion  of  Re suits 


The  results  of  this  reasearch  fall  into  three  main  categories 
the  general  importance  of  the  handling  of  the  implementation  process  to 
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the  project  outcomes,  the  differential  demands  placed  on  the  process  by 
different  technologies,  and  the  low  degree  of  perceptual  congruence  be- 
tween users  and  designers  in  projects  where  the  users  were  dissatisfied 
with  outcomes.  Of  these,  the  first  two  were  expected.  The  third  result, 
however,  was  quite  unexpected,  and  we  shall  turn  to  it  first. 

Our  data  indicate  that  consultants  are  much  less  likely  to  view 
a  project  as  unsuccessful  than  are  clients.  We  must  point  out  that  none 
of  the  projects  we  have  looked  at  are  failures  in  the  sense  of  not  being 
used.  All  were  installed  and  were  used  for  some  period  (in  fact,  we  know 
of  only  one  system  which  was  not  being  used  at  the  time  the  data  for  this 
study  were  collected).  Thus,  the  measure  of  project  success  is  consider- 
ably more  stringent  than  the  simple  criterion  of  system  use.  This  measure, 
user  satisfaction  with  project  outcomes,  is  far  more  appropriate  to  the 
"service"  orientation  which  we  have  suggested  is  necessary  for  effective 
MS  implementation  than  would  be  the  system  use  criterion  (which  suggests 
a  "product"  view  of  implementation).  Apparently,  however,  many  consult- 
ants do  not  operate  in  this  service  mode  and  are  unable  (or  unwilling) 
to  recognize  when  a  client  is  dissatisfied  with  a  project  even  though  he 
is  using  the  system. 

This  difference  between  client  and  consultant  perceptions  is 
not  limited  to  outcomes.  Looking  at  perceptions  of  the  implementation 
process  itself,  we  find  substantially  less  agreement  between  users  and 
designers  in  those  cases  where  the  user  is  not  satisfied  than  we  do  in 
those  cases  where  the  user  is  satisfied.  What  is  more,  these  differences 
tend  to  be  largest  at  the  process  stages  which  appeared  to  be  most 
critical  for  success  in  that  type  of  project.  Generally,  while  we  find 
a  number  of  differences  between  the  process  perceptions  of  satisfied 
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and  dissatisfied  clients,  we  find  far  fewer  differences  between  consultants 
involved  in  projects  with  satisfied  users  and  those  with  dissatisfied  users. 
Because  of  this  inability,  or  unwillingness,   by  consultants   to  differentiate 
between  successful   and  unsuccessful   projects,   the  bulk  of  our  analysis  has 
focused  on  the  clients  only. 

It  is  worth  noting  here  a  parallel    between  MS  implementation  and 
marketing.     The  client  in  an   implementation  effort  is  truly  a  buyer  of  a 
service;   it  is  his  needs  which  the  consultant  (or  seller)   is  trying  to 
meet  (see  Stabell,   1974,   for  a  more  detailed  discussion  of  this  buyer-seller 
relationship).     The  client's  perceptions,   then,  are  the  critical   ones  for 
understanding  implementation.     They  will   reflect  the  difference  between  a 
consultant  who  takes  a  "sales"  approach  --  offering  a  product  --  and  one  who 
takes  a  "marketing"  approach  --  attempting  to  develop  and  meet  a  felt  need. 
Many  consultants  in  the  MS  area  may  not  recognize  the  difference  between 
these  two  approaches,   so  it  is  only  through  the  user's  perceptions  that  we 

can   tap  into   this   critical    difference  in   process. 

The  primary  hypothesis   test  in  this   study  was,   essentially,    that 
differences   between   successful   and  unsuccessful    implementation  efforts    (as 
defined  by  the  user's  achievement  of  his   goals  for  the  project)   could  be 
accounted  for  by  differences   in   the   implementation  processes  followed  by 
the  projects.      In  other  words,   our  contention  was   that  the  problem(s)  which 
led   to  user  dissatisfaction  could  be  found  in   the  nature  of  the   implementa- 
tion  process;  more   specifically,   it  could  be   traced   to  a  failure   to  adequate- 
ly deal   with  and  resolve  certain   issues  which  are   implied  by  the  Lewin/Schein 

theory  of  change. 

The  data  show  that  there  are   significant  differences   in   the 

processes  followed  by  successes  and  failures   (as  defined  by  the  user's 

satisfaction  with  project  outcomes).      Systems  were  divided  into  three 

groups  based  on   their  implied  organizational    complexity   (which   is  not 

necessarily  related   to   technical    complexity),   and   in  each  of  these  groups. 
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satisfied  users  reported  significantly  better  Termination  or  Refreezing 
efforts   than  did  dissatisfied  users.     That  is,   the  transfer  of  responsi- 
bility for  the   system  from  consultant     to  client  and  the  confirmation  of 
necessary  new  behavior  patterns  was,   in  almost  all   cases,   better  handled 
in  successful   projects   than  in  unsuccessful   ones.      It  is  true  that  in  a 
number  of  cases   the  failure  to  adequately  handle  this  Termination  stage   is 
likely  to  reflect  problems  which  arose  at  earlier  stages  of  the  process 
and  were  carried  through,  unresolved,  until    the  project  ended.     However, 
there  are  unsuccessful    projects   in  our  sample  which  give  no  indication  of 
any  problem  until    they  reach  this  Termination   (or   institutionalization) 
stage.     No  other  process  stage  was  as  strongly  related  to  success  as  was 
Termination.     This  result  is  highly  congruent  with  Sorensen  and  Zand's 
finding  that  the  Refreezing  stage  was  much  more  strongly  related  to  out- 
comes than  either  of  the  other  two  stages  in  the  Lewin/Schein  theory  of 
change.      Indeed,   this  result  adds  emphasis  to  Dickson  and  Powers'    con- 
tention that,     to  users,   implementation  is^  institutionalization,  not  the 
system  installation  phase  which  technicians   tend  to  equate  with   it.     Clear- 
ly,  these  results  suggest  that  as  consultants  we  must  pay  considerably 
more  attention  to  the  activities   following  system  installation   than  we 
have  in  the  past;  we  must  not  be  in  a  hurry  to  terminate  the  relationship 
with  the  client  as  soon  as  the  system  begins  operating. 

Other  than  Termination,  no  stage  of  the  implementation  cycle 
bears  a  clear  and  consistent  relationship  to  outcomes.     Other  stages  do 
exhibit  significant  differences  between  successes  and  failures  in  one  or 
two  of  the  three  complexity  groups,   but  many  of  these  differences  dis- 
appear when  we  take   the  project's  Termination  score   into  account.     The 
limited  data  which  are  then  available  can  do  no  more   than  suggest  some 


17 


patterns  which  lead  to  success  or  failure.  The  patterns  which  seem  to 
emerge  differ  across  complexity  groups.  Essentially,  it  appears  that 
for  systems  of  higher  organizational  complexity,  the  substantive  issues 
of  the  Entry,  Diagnosis,  and  Planning  stages  (Unfreezing  in  Lewin/Schein 
terminology)  —  e.g.,  agreeing  on  goals  and  objectives,  gaining  wide  in- 
volvement of  organizational  personnel,  and  developing  a  good  understanding 

of  both  problem  and  solution  --  are  important  contributors  to  the  eventual 
outcomes  of  the  project.  The  procedural  and  mechanical  issues  at  the 
Planning,  Action,  and  Evaluation  stages  (the  Moving  phase)  seem  to  havo 
less  bearing  on  success  in  these  higher  complexity  projects.  In  projects 
of  lower  complexity  the  Unfreezing  issues  may  still  be  important,  but 
they  are  relatively  less  important,  as  here  the  procedural  and  technical 
activities  of  the  Moving  stage  appear  to  be  more  directly  related  to 
project  outcomes. 

The  patterns  we  have  described  are  merely  suggestions.  They  are 
consistent  with  the  "theory  of  implementation"  we  view  as  most  appropriate. 
We  find  some  evidence  in  the  data  which  suggests  these  patterns  are  present. 
This  evidence  varies  in  quality  and  weight,  and  more  conclusive  results 
would  be  desirable.  The  data,  however,  are  too  limited  to  provide  these 
resul ts . 

5.  Implications  for  Research  and  Practice 

The  interests  of  scholars  and  practitioners  are  very  closely 
alligned  in  the  area  of  MS  implementation.  Both  need  models  which  help 
them  understand  this  phenomenon;  the  scholar,  so  that  he  can  study  it 
and  refine  this  understanding;  the  practitioner,  so  that  he  can  guide 
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it  to  achieve   the  most  desirable  outcomes.     Our  purpose   in  this   research 
has  been   to  articulate  and  test  one  such  model,  a  model   of  the  implemen- 
tation  process.     Our  contention   is   that  process  provides  a  more  meaning- 
ful   framework  for  viewing  a  variety  of  implementation  situations   than  do 
competing  models,   most  notably  the  factor  approach.      Ultimately,  we  argue, 
this  process  view  can  provide  us  with  considerably  better  action  implica- 
tions  than  can  other  approaches  to  implementation   research.     We  have  re- 
viewed the  evidence   that  was  developed   in   this  study;   our  purpose,   now 
is   to  translate  our  results   into  implications  for  action  for  both  con- 
sultants and  managers. 

5.1      Implication  for  Consultants 

There  are  two  basic  messages  for  consultants   to  be  found  in  this 
study.      First  is   the   fact  that  not  all    projects  are  alike.      Systems   differ 
from  one  another   in   the  degree  of  organizational /implementation   complexity 
they  imply.      That  is,   implementation  has  numerous   dimensions  --   technical, 
cognitive,    interpersonal,   political.      For  some   (low  compU?xity)   systems, 
the   technical    dimension   is   the  dominant  one.     But,    for  other,  more  complex 
systems,   additional    dimensions  become  more   salient,  and  may,   in  fact, 
overshawdow  the  purely  technical   aspects.     We  saw  this  in  the  differences 
among  our  three  groups  of  projects.     For  systems   in  the  two  lower  complex- 
ity groups,    there  seemed   to  be  a  fairly  strong  connection  between   the 
handling  of  the   technical   aspects  of  the  project  and  success;   but,   for 
the  most  complex  systems,   the  non-technical   dimensions  appeared  to  be 
more   important. 

The  implication  of  this  difference  is  quite  simple.      Different 
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projects  require  different  types  of  skills,  and  the  consultant  must  learn 
to  recognize  the  skills  needed  in  the  particular  situation.  He  must  be 
artful  enough  to  vary  his  emphasis  and  apply  those  talents  most  appropriate 
to  the  circumstances  he  is  facing;  and,  he  should  be  honest  enough  to  back 
away  from  those  projects  requiring  skills  he  does  not  possess.  We  rea- 
lize that  this  is  a  rather  Utopian  prescription.  Admitting  to  a  lack  of 
requisite  skills  is  difficult  enough  when  the  skills  in  question  are  only 
technical  ones;  it  is  undoubtedly  more  difficult  when  the  real  issue  may 
be  interpersonal  skills.  But,  difficult  or  not,  the  prescription  is  ap- 
propriate. Gorry  and  Scott  Morton  (1971)  suggested  that  one  very  possibly 
needed  different  people  to  build  complex,  management  oriented  decision 
support  systems  than  to  build  conventional  information  sy^^tems.  Our  data 
support  this  contention. 

The  second  major  point  on  which  this  study  speaks  to  consultants 
is  that  of  their  relationship  with  their  clients.  There  are  several  as- 
pects to  this.  Perhaps  the  most  important  is  how  the  consultant  defines 
his  role.  He  has  a  critical  choice  to  make;  he  can  act  as  a  process  con- 
sultant or  he  can  act  as  a  technician.  Schein  has  suggested  (personal 
communication)  that  this  is  the  most  important  decision  the  consultant 
has  to  make  in  the  course  of  a  project;  and,  he  must  make  it  at  the  very 
start  of  that  project.  His  decision  at  this  point  will  impinge  on  every 
aspect  of  the  project  from  start  to  finish.  If  he  wishes  to  act  as  a 
technician,  the  likelihood  of  his  truly  understanding  the  user's  needs, 
goals,  and  general  perspective  is  severely  diminished;  and,  with  this, 
so  are  the  chances  of  success!  What  is  more,  the  more  complex  the  pro- 
ject, the  greater  the  damage.  Success,  particularly  in  high  complexity 
projects,  demands  that  the  consultant  understand  the  user.  Achieving 


20 


this  understanding  normally  requires  a  conscious  effort  by  the  consultant, 
and  this  implies  a  need  to  behave  as  a  process  consultant,  not  a 
technician. 

The  other  key  apsect  of  the  client-consultant  relationship 
issue   is   that  of  defining  who   the  client  is   (or  clients  are).     Our  data 
show  clearly  that  not  all   users   see  a  single  project  in   the   same  way, 
that  each  has  his  own   unique  set  of  needs  and  desires.      This  result  points 
out  the  individual   nature  of  implementation;   it  must  be  viewed  as  a  set  of 
relationships  between   individuals.      For  the  consultant  this  implies  a  need 
to  identify  all  ^^V  actors  in  the  client  group,  and  to  negotiate  an  ap- 
propriate contract  with  each  of  them.      It  is  not  enough  to  work  with  one 
user  in  a  multi-user  system,  and  assume  that  he  can  adequately  represent 
the  views  of  all  others.     True  participation  of  all   relevant  users   (and 
other  affected  personnel)   is  necessary.     Clearly,    this  adds  considerably 
to  the  consultant's  work  load,  and  in  some  cases  may  be  infeasible.     But, 
the  consultant  must  recognize --that  by  failing  to  deal   with  each  person 
individually,   he  increases  the  probability  that  some  participants  will 
be  dissatisfied  with  the  project  results. 

We  can  summarize  all   of  the  implications  for  the  consultant  in 
one  simple  statement:     He  must  learn   to  be  a  diagnostician.     His  role 
truly  should  be  a  "clinical"   one,   as   he  must  study  each  situation   to 
learn  what  makes  it  unique,    to  ferret  out  the  critical   aspects   in   that 
setting   (for  further  comments  on   the  clinical   nature  of  the  consultant's 
role,    see  Keen,   1975). 

5.2     Implications  for  Managers 

Finally,   we  turn   to   the  user.     What  can  he  do   to  assure   that  he 
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receives  the  most  for  his  investment  in  system  development?     We  can  divide 
his  actions  into  two  groups  --  those  things  he  should  do  by  himself  and 
those  things  he  should  do  in  conjunction  with  the  consultant. 

We  will   consider  first  what  he  can  do  alone,  as  these  are  actually 
prerequisites  to  the  other  actions  he  can  take.     First,  he,  like  the  con- 
sultant, must  recognize  that  projects  differ  from  one  another;   that  the 
demands  placed  on  him  and  his  organization  will   vary  form  project  to  pro- 
ject.    A  key  aspect  of  this  is  the  variation   in  the  degree  of  change  im- 
plied by  different  technologies.     The  potential   system  user  must  learn  to 
understand  both  these  differences  and  his  own  capacity  for  change.     A  user 
who  is  unwilling  to  consider  new  modes  of  problem  solving  is  wasting  his 
own  (and  the  consultant's)   time  and  money  if  he  asks  for  a   sophisticated, 
model -based,  on-line  decision  support  system.     He  must  take  the  time  to 
think  through  both  the  demands  for  change  implied  by  the  system  and  the 
capacity  for  and  willingness  to  change  he  and  his  organization  possess. 
If  there  is  not  a  match  between  demands  and  capacity,   the  project  should 
be  abandoned,  or  at  least  carefully  redefined. 

Closely  allied  to  this  assessment  of  demands  and  capacity  for 
change  is  another  simple  step  the  user  can  take;   that  of  articulating 
carefully  his  goals  and  objectives  for  the  project.     This  may  seem  to 
be  a  trivial    suggestion.     Nonetheless,   it  is  an  important  one;   for  it  is 
only  by  clarifying  for  himself  exactly  what  he  hopes  to  achieve  that 
the  user  can  judge  whether  the  project  has  a  realistic  chance  of  reach- 
ing this  goal . 

A  key  aspect  of  both  of  these  suggestions   is   that  the  user  must 
realize  that  he^  has  a  tremendous  responsibility  for  the  progress  of  an 
implementation  effort.     Hiring  a  consultant  in  no  way  lessens   this 
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responsibility.     The  user  must  be  willing  to  make  the  project  a  joint 
effort  if  he  wants  it  to  succeed.     He  must  recognize  that  his  time  and 
commitment  are  required  whether  or  not  a  consultant  is   involved.      If  he 
is  not  willing  to  give  this  time  and  commitment,   the  project  should  be 
dropped. 

The  other  implications  for  managers  arising  from  this  research 
concern  their  relationships  with  consultants.     Three  interrelated  pres- 
criptions seem  warranted.     First,   the  user  must  demand  that  the  consultant 
have  the  skills  necessary  for  the  type  of  project  being  considered.     This 
implies  that  the  user  must  understand  the  different  demands  of  different 
project  types,  and  must  have  some  basis  for  judging  the  consultant's 
capabilities.     Next,   the  user  must  demand  that  the  designer  behave  as  a 
process  consultant;   that  he  not  view  his  role  as  one  of  simply  injecting 
technical   expertise,   but  rather  one  of  working  with  the  client  organiza- 
tion to  help  it  improve  its  functioning.     Finally,   in  order  to  assure 
that  these  first  two  demands  are  being  met,   the  user  should  periodically 
test  the  match  of  his  perceptions  with  those  of  the  consultant.     Such 
an  action  should  force  the  project  to  stay  "on  course",   and  thus 
eliminate  the  type  of  situation  we  observed  in  our  sample,  where  users 
and  designers  had  marked  differences  in  perceptions  about  both  process 
and  outcomes. 

6.  Conclusions 

We  argued  earlier  in  this  paper  that  one  of  the  most  serious 
defects  in  existing  research  on  MS  implementation  is  that  it  fails  to 
focus  on  the  management  of  the  process,  that  it  has  studied  those  aspects 
of  the  implementation  situation  over  which  we  have  the  least  control. 
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Focusing  on  process,  on  the  other  hand,  should  lead  to  an  understanding  of 
implementation  upon  which  we  can  act,  since  this  understanding  should  be 
in  terms  of  those  aspects  of  implementation  over  which  we  have  the  great- 
est control,  our  own  behavior.  We  have  now  looked  at  data  gathered  from 
a  snail  sample  of  projects,  and  have  discussed  some  implications  arising 
from  this  data.  As  we  had  hoped,  the  data  bear  not  on  structure  or  other 
non-controllables,  but  rather  on  the  actions  which  users  and  designers  can 
take.  The  task  now  is  to  test  these  actions  in  practice,  to  determine 
whether  they  do  lead  to  the  outcomes  that  have  been  suggested  here. 
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